home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Gold Collection / Software Vault - The Gold Collection (American Databankers) (1993).ISO / cdr12 / dkit0593.zip / DNEKOPOL.002 < prev    next >
Text File  |  1993-03-11  |  22KB  |  519 lines
  1.  
  2.                DoorNet Backbone Operating Procedures
  3.               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  4.  
  5.    "This document adopted this 10th day of March 1993."
  6.  
  7.  
  8.                           Table of Contents
  9.                          ~~~~~~~~~~~~~~~~~~~
  10.  
  11.                 Purpose of this Document
  12.                      Brief Description
  13.                 Zone Echomail Coordinator
  14.                      Zone Hubs
  15.                      Eroster/DnetStat.mdd
  16.                 Region Echomail Coordinators
  17.                      Region Hubs
  18.                 Backbone Conference Moderators
  19.                      Duties of Moderators
  20.                      Recognition of Moderators
  21.                 Operating Procedures
  22.                      Echomail Message Standards
  23.                      Adding Conferences to the Backbone
  24.                      Removing Conferences from the Backbone
  25.                      Routed Netmail
  26.                      Gating Backbone Mail
  27.                      Encryption
  28.                 Echo Conference Criterion
  29.                      General Conferences
  30.                      Restricted Conferences
  31.                      Specific Support Conferences
  32.                 Changes to this Document
  33.  
  34.  
  35.  
  36. Purpose of this Document
  37. ~~~~~~~~~~~~~~~~~~~~~~~~
  38.  
  39. This document sets forth the operating procedures used by the DoorNet
  40. Backbone Echomail System at the International level.  It describes how
  41. the Zone Hubs (Stars), International and Zone Echo Coordinators and
  42. Regional Echo Coordinators make up the "Backbone" system for echomail
  43. distribution.
  44.  
  45. Any part of this policy which conflicts with Local, State or Inter-
  46. national Laws shall be deemed obsolete.  Changes necessary to overcome
  47. any conflicts shall be amended immediately by the appropriate IZ/ZC/ZEC
  48. until such a time they can be ratified into this document.
  49.  
  50. (The operation of the Backbone within a region or net is not covered by
  51. this document.)
  52.  
  53. An echomail conference is a message base or forum, distributed under a
  54. specified echomail conference name, dealing with a defined area of
  55. interest.  Echomail conferences are hereafter referred to simply as
  56. conferences.
  57.  
  58. Echomail Hubs are nodes who distribute echomail.  The Echomail Hubs
  59. are hereafter referred to simply as Hubs.  Zone Hubs distribute
  60. echomail at the zone level.  Region Hubs distribute echomail at the
  61. region level.  Net Hubs distribute echomail at the net level.
  62.  
  63.  
  64. Zone Echomail Coordinator
  65. ~~~~~~~~~~~~~~~~~~~~~~~~~
  66.  
  67. The Zone Echomail Coordinator (ZEC) oversees the operation of the
  68. Backbone at the zone level.  The ZEC coordinates routing and schedules
  69. to ensure reliable and efficient availability of Backbone echomail
  70. while avoiding creation of duplicate messages.  The current ZEC can be
  71. identified from the "DOORNET_ZEC", or the 75/1 - 76/1 listing in the
  72. Dnetlist.
  73.  
  74.  
  75. Eroster/DnetStat.mdd
  76. ~~~~~~~~~~~~~~~~~~~~
  77. The ZEC maintains a list of Backbone conferences in a text file called
  78. DOORNET.NA, also distributed in archived format under EROSTER.mdd
  79. This file must be reformatted to be used as a forward-list by programs
  80. such as AreaFix.  The ZEC also maintains a list of conferences seeking
  81. to be added to the Backbone.  This is a text file called DNETSTAT.mdd.
  82. The ZEC distributes these files to the Zone Hubs on a bi-weekly basis.
  83.  
  84. DNETSTAT.mdd will include  submissions received via netmail or posted
  85. within the D_ECHOREQ conference "To:" either "Steve Lin" or "ZEC" using
  86. an appropriate subject heading.  DNETSTAT.mdd will contain submissions
  87. for backbone status for no less than 90 days of inclusion.  The following
  88. format will be used: <if I was the ZEC I'd write a program for this ;)
  89.  
  90. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  91. Submission Date:                Echo Tag:
  92. Description    :
  93. Current Path   : List of system aka's currently receiving conference
  94. REC Votes      : List of RECs currently supporting conference
  95. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  96.  
  97. The following syntax: EROSTER.mdd, where the "m" is a hexadecimal specifier
  98. from 1 to C that designates the month in which the Echo Roster has been
  99. released, and the "dd" is a decimal specifier from 01 to 31 that designates
  100. the day in which the Echo roster has been released. This method of naming
  101. the Echo roster archive makes it very easy for a sysop to determine which
  102. Echo roster is the most recent in a certain year. Note that there is a
  103. rollover phenomenon at the beginning of each year. We recommend that older
  104. Echo rosters be deleted in favor of new ones.  DNETSTAT.mdd follows this
  105. same order of specifiers.
  106.  
  107.  
  108. Zone Hubs
  109. ~~~~~~~~~
  110.  
  111. The ZEC appoints Zone Hubs (Stars) to distribute Backbone echomail at
  112. the zone level.  The ZEC may also serve as a Zone Hub if s/he so
  113. desires.
  114.  
  115. Each Zone Hub carries all of the Backbone conferences.  Each also
  116. distributes the EROSTER.mdd and DNETSTAT.mdd files, as received from the
  117. ZEC, to the Region Hubs they connect with.
  118.  
  119. The ZEC and Zone Hubs maintain an emergency backup plan should one of
  120. the Zone Hubs experience problems.
  121.  
  122.  
  123.  
  124. Region Echomail Coordinators
  125. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  126.  
  127. The Region Echomail Coordinator (REC) oversees the operation of the
  128. Backbone at the region level.  The REC coordinates routing and
  129. schedules to ensure reliable and efficient availability of Backbone
  130. echomail while avoiding creation of duplicate messages.  The current
  131. RECs can be identified from the ,1,Regional_Echo_Co or the xxx/1 (where
  132. "xxx" = the region number) listings in the Nodelist.
  133.  
  134.  
  135. Region Hubs
  136. ~~~~~~~~~~~
  137.  
  138. The REC appoints Region Hubs to distribute Backbone echomail at the
  139. region level.  The REC may also serve as a Region Hub if [s]he so
  140. desires.
  141.  
  142. The REC decides which Region Hub connects to each of the Zone Hubs.
  143.  
  144. Each REC and Regional Hub carries all of the Backbone conferences.  Each
  145. also distributes the EROSTER.mdd and DNETSTAT.mdd files, as received from
  146. the ZEC/REC respectively, into the Region's networks they connect with.
  147.  
  148. The REC and Regional Hubs maintain an emergency backup plan should
  149. one of the Zone Hubs, REC and/or Regional Hubs experience problems.
  150.  
  151. Region Hubs make available all of the Backbone conferences with
  152. exceptions to be noted later about restricted echo access.
  153.  
  154. Nothing in this provision requires that a REC or Region Hub must
  155. import any conference to the extent of adverse economic impact.
  156.  
  157.  
  158. Backbone Conference Moderators
  159. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  160.  
  161. Backbone Conference Moderators (Moderators) preside over conferences.
  162. The Backbone has no desire to interfere with the internal affairs of a
  163. conference in so much as they do not disturb the operation of the
  164. Backbone.
  165.  
  166. A Moderator need not be either a Sysop or a member of Doornet.  If the
  167. Moderator is not a member of Doornet, s/he must list an address in a
  168. publicly available Dnetlist of any network, so that s/he can be
  169. contacted if the need arises via netmail.
  170.  
  171.  
  172. Duties of Moderators
  173. ~~~~~~~~~~~~~~~~~~~~
  174.  
  175. IZEC is moderator of D_Moderator Echo or may designate someone to that
  176. position in his/her place.
  177.  
  178. IZC is moderator of D_SYSOP and D_COORD and may appoint
  179. or designate others to assist if needed.
  180.  
  181. Moderators are responsible for:
  182.  
  183.     1)  Seeing that messages in their conference correspond to the
  184.         conference's theme.
  185.  
  186.     2)  Updating their conference listing with the ZEC via netmail
  187.         so the appropriate modifications can be noted in EROSTER.mdd
  188.  
  189. If a Moderator believes that a node is violating a conference rule,
  190. s/he may authorize the feed to that node be severed.  This
  191. authorization is made in direct written form (netmail), to the Hub
  192. feeding the offending node, with a copy to the offending node.
  193.  
  194.  
  195. Recognition of Moderators
  196. ~~~~~~~~~~~~~~~~~~~~~~~~~
  197. A Moderator is recognized as follows:
  198.  
  199.     1)  Upon formation of a conference, the person who forms the
  200.         conference is the Moderator.
  201.  
  202.     2)  Upon resignation or replacement of an existing Moderator, the
  203.         conference's rules define how the new Moderator is selected.
  204.  
  205.     3)  Should a conference which originates inside of DoorNet be
  206.         without a moderator for over 30 days, the ZEC may select
  207.         a new Moderator.
  208.  
  209. Moderators are encouraged to appoint Co-Moderators to assist them in
  210. their duties and to stand in for them in their absence.
  211.  
  212.  
  213. Operating Procedures
  214. ~~~~~~~~~~~~~~~~~~~~
  215.  
  216. Echomail Message Standards
  217. ~~~~~~~~~~~~~~~~~~~~~~~~~~
  218. FTSC specifications FTS-0001 and FTS-0004 are followed.  All Backbone
  219. nodes use the pathline option to comply with network addressing.
  220.  
  221.  
  222. Adding Conferences to the Backbone
  223. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  224. The ZEC will add conference(s) to the Backbone when the following
  225. requirements are met:
  226.  
  227.     1)  The conference is listed in the published EROSTER.mdd
  228.  
  229.     2)  The moderator either sends a netmail request to the ZEC or
  230.         posts the request, addressed to "Backbone", in the
  231.         D_ECHOREQ conference.
  232.  
  233.     3)  Four (4) RECs request that the Backbone carry the conference to
  234.         their regions to the ZEC either via netmail or within the
  235.         D_ECHOREQ conference.
  236.  
  237.  
  238. Removing Conferences from the Backbone
  239. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  240. The ZEC may drop a conference from the Backbone when any of these
  241. situations occur:
  242.  
  243.     1)  The conference is not updated in the EROSTER.mdd at least
  244.         once every 6 months by the Moderator.
  245.  
  246.     2)  The moderator either sends a netmail request to the ZEC or
  247.         posts the request, addressed to "Backbone", in the D_ECHOREQ
  248.         conference.
  249.  
  250.     3)  There are no longer four (4) RECs requesting that the Backbone
  251.         carry the conference to their regions.
  252.  
  253.     4)  The Moderator fails to properly carry out his/her duties,
  254.         as described in "Duties of Moderators".
  255.  
  256.     5)  The conference is without a Moderator for over 30 days.
  257.  
  258.     6)  The traffic level in the conference falls below 5 messages
  259.         over a two month period.
  260.  
  261.  
  262. If any of these conditions exist and noted by/to the ZEC, the ZEC will
  263. either select/request volunteer(s) for a new Moderator (if condition #5
  264. exists), or post a notification within the D_ECHOREQ conference
  265. indicating that a particular conference will be removed in "30" number of
  266. days unless conditions are changed to meet the above specifications.
  267.  
  268. Special Note:  The above criterions for "Adding/Removing" Backbone
  269.                conference areas apply only to DoorNet(tm) areas.
  270.                Special considerations apply to the "Specific Support
  271.                Conference" areas as stated below under same.
  272.  
  273.  
  274. Routed Netmail
  275. ~~~~~~~~~~~~~~
  276. Backbone nodes accept routed netmail from any node who connects with
  277. them for Backbone conferences.  Any netmail message with a valid
  278. Doornet destination, regardless of its origin, is accepted.  Routed
  279. netmail may be routed along echomail paths or to a ZC, RC, or NC who
  280. has agreed to handle such mail.
  281.  
  282. Gating Backbone Mail
  283. ~~~~~~~~~~~~~~~~~~~~
  284. Gating Doornet specific conferences is not allowed (e.g. D_xxxx).  Any
  285. product oriented conferences may be gated to/from Doornet at the
  286. permission of the designated Moderator/Author.
  287.  
  288.  
  289. Encryption
  290. ~~~~~~~~~~
  291. The transportation of "encrypted" net/echomail via the Doornet Backbone
  292. in the United States, using the software named "Pretty Good Privacy"
  293. (currently version 2.1 released as PGP21.*) is not allowed.  Due to
  294. legal ramifications with licensing limitations of the PGP software or
  295. "Pretty Good Privacy" in the United States, as stated in the file
  296. named "PGPDOC2.*" under "Legal Issues".  At such a time when the
  297. licensing of "Pretty Good Privacy" software is either entered into the
  298. Public Domain or readily available on an International level this network
  299. will make provisions by vote for future allowance.
  300.  
  301.  
  302. Echo Conference Criterion
  303. ~~~~~~~~~~~~~~~~~~~~~~~~~
  304.  
  305. This section reflects the operating guidelines for each member of DoorNet
  306. in respect to the echomail conferences available via the "Backbone".  It
  307. will include operating aspects of "required", "general" and "restricted"
  308. echo conferences.  The individual conference name will be described in
  309. detail via the EROSTER.mdd file distributed via DOORDIST the DFN filebone
  310. area.  This document will not use the echo tag names used for distribution
  311. with the exception of the "required" and "restricted" conference(s).
  312. Echo conference tag names used will be obtained from the current release
  313. of EROSTER.mdd that can be file requested from any "Administration Node"
  314. within Doornet.  The status of conferences within the DNETSTAT.mdd file
  315. will be made available upon achieving "Backbone" status.
  316.  
  317.  
  318. General Conferences
  319. ~~~~~~~~~~~~~~~~~~~
  320. The "General echo conferences" are public conference echo areas open to
  321. all.  The following conferences are required to be carried by all Doornet
  322. members, and to be made available to the general public:
  323.  
  324. Echo tag                Brief Description
  325. ~~~~~~~~                ~~~~~~~~~~~~~~~~~
  326. D_ADVENTURE  - Discussions about adventure, rpg, war door games... etc.
  327. D_CHANCE     - Discussions about door games of chance, chess, dice... etc.
  328. D_DOORGAMES  - General chit chat about any door game  (Note naming - ok?)
  329. D_ECHOREQ    - Requests for new backbone, regional echos or removal of
  330. D_FILES      - Announcements of new releases of Doors and Door Utilities.
  331. D_INTERBBS   - Discussions about interbbs gaming, may be used to form games.
  332. D_SPORTS     - Discussions about sport related door games
  333. D_TRIVIA     - Discussions about trivia related door games
  334.  
  335.  
  336. All other "general or public" conferences not listed here are listed as
  337. such in the EROSTER.mdd.  Please make all general "Backbone" areas
  338. available to the general public.
  339.  
  340. Restricted Conferences
  341. ~~~~~~~~~~~~~~~~~~~~~~
  342.  
  343. The following conferences are considered restricted to certain group(s).
  344. Some of which will be "required" conference areas and will be noted so.
  345.  
  346.  
  347. Echo tag                Brief Description
  348. ~~~~~~~~                ~~~~~~~~~~~~~~~~~
  349. D_ADULT_DOORS-  "Not Required" however this is a DoorNet specific echo.
  350.                 Discussions of Doors that relate to mature (Adult) themes.
  351.                 While profanity will not be tolerated, the sysop may consider
  352.                 limiting the echo to users over 18 due to the nature of the
  353.                 topics.
  354.  
  355. D_SYSOP      -  "Required" - for administration use and announcements.
  356.                 Discussions pertaining to Doornet operations, changes and
  357.                 policy amendments, ratifications, votes... etc.
  358.  
  359. D_DEVELOP    -  Door Author's support area, publicly released door or
  360.                 door type utility a must for access.  REC's must receive
  361.                 netmail from the author requesting access to this
  362.                 conference and from which node the author will access
  363.                 said conference from.
  364.  
  365. D_MODERATOR  -  "Required" by Doornet Moderators and ZEC Only.  Only
  366.                 Moderators listed in the EROSTER.mdd can have access
  367.                 to this area.  (All RECs please note)
  368.  
  369. D_COORD      -  D_NC, D_EXEC, and D_RC will make up this area.  We need
  370.                 a conference to maintain a professional profile within
  371.                 the network.  If International, Zone or Regional contact
  372.                 need to take place without the influx necessary from the
  373.                 node level we can do it here and get fast results.  All
  374.                 *[E]C's should have access to this area.
  375.  
  376. All D_???????? conference areas are a "Trademark" of DoorNet(tm).  Any
  377. gating of DoorNet specific conference areas must be approved by IZC.
  378.  
  379.  
  380. Specific Support Conferences
  381. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  382.  
  383. The echomail distributed via means of Backbone routing specific to a
  384. certain door or programming group will be supported by the Doornet
  385. backbone with the appropriate requirements met.  The criteria(s)
  386. necessary for "Specific Support Conference(s)" to gain backbone status
  387. are as follows:
  388.  
  389.         a.  The "Door or Group(s)" designated Author make a request
  390.             to the IZEC, ZEC and local REC to carry a new Product
  391.             Specific conference on the Backbone.
  392.  
  393.         b.  Request shall be made either via NetMail or within the
  394.             D_ECHOREQ conference area.
  395.  
  396.         c.  Door Author(s) shall commit time to promote and Moderate
  397.             requested conference area, or shall appoint a person
  398.             knowledgable of their product as Moderator/Liason
  399.  
  400.         d.  Door Author(s) will make attempts of recognition within
  401.             DoorNet generic conference areas to promote their product
  402.             and Special Support Conference area on a regular basis.
  403.  
  404. These mild guidelines are to promote the use of DoorNet(tm) by the
  405. Door Authors.  Backbone status of "Product Specific" conferences will
  406. only guarantee said conference(s) will be available from the "Star"
  407. systems.  All *ECs will not be required to carry this class of
  408. conference unless regional downlinks request it.
  409.  
  410. It will be left up to the Author or designated Moderator as to who can
  411. access their conference, this of course maybe subject to ruling(s) of the
  412. ZEC and associated council.  Typically the designated Moderator will
  413. either be one of, or the supporting Author(s) of said "DOOR" program(s).
  414. Designation of access shall be listed in DOORNET.NA, meaning the
  415. read/write access to the conference being:
  416.  
  417.         General - Open to the public
  418.         Sysop   - Sysop Only conference (R)
  419.         Beta    - For noted Beta testers, Both Sysop and User (R)
  420.  
  421. whereas (R) is "Restricted".  The following conference areas are currently
  422. carried by the DoorNet(tm) backbone system.  For a complete listing of
  423. available areas, please see the latest EROSTER.mnn ...
  424.  
  425.  
  426. Echo tag                Brief Description
  427. ~~~~~~~~                ~~~~~~~~~~~~~~~~~
  428. AOTD ----------------------------------------------------- AOTD Support
  429. Restriction "None"       Moderator: Steve Lin (75:75/1)
  430.  
  431. BOI -------------------------------------------- BBS Online Interface Support
  432. Restriction "None"       Moderator: Andrew Mead (75:7919/417)
  433.  
  434. DOORSOURCE ----------------------------------------------- DoorSource Support
  435. Restriction "?"          Moderator: Todd Miller (75:75/3)
  436.  
  437. DWARZNET ------------------------------------------------ Dragon Wars Support
  438. Restriction "None"       Moderator: Bruce Ruona (FN 1:2280/1)
  439.  
  440. IMPERIUM --------------------------------------------------- Imperium Support
  441. Restriction "?"          Moderator: Chris King (FN 1:103/315)
  442.  
  443. INTELECHARGE ---------------------------------------- Intelecharge Support
  444. Restriction "?"          Moderator: Pat Carter (75:7615/102)
  445.  
  446. INTELESYS ------------------------------------------- Intelesys Support
  447. Restriction "?"          Moderator: Pat Carter (75:7615/102)
  448.  
  449. MEP -----------------------------------------Minds Edge Productions Support
  450. Restriction "None"       Moderator: Dion Loy (75:8010/303)
  451.  
  452. MICRONET -------------------------------------------- Micronet Support
  453. Restriction "?"          Moderator: ???????
  454.  
  455. MELEE ----------------------------------------------- Banzai Software Support
  456. Restriction "?"          Moderator: Kevin Higgins (75:7719/1)
  457.  
  458. MCSOFT ------------------------------------------ Motor City Software Support
  459. Restriction "?"          Moderator: Peter Kling (75:7518/2)
  460.  
  461. MYCROFT -------------------------------------------- Mycroft Software Support
  462. Restriction "?"          Moderator: David Fife (75:100/1)
  463.  
  464. NUGI ---------------------------------------------- N.U.G.I. Software Support
  465. Restriction "?"          Moderator: Dave Wendling (75:7413/2)
  466.  
  467. PGWARE ------------------------------------------------------- PGWare Support
  468. Restriction "?"          Moderator: Scott Philips (75:75/3)
  469.  
  470. PONYWARE --------------------------------------------------- Ponyware Support
  471. Restriction "?"          Moderator: Craig Barnett (75:7602/2)
  472.  
  473. QENFORCE ---------------------------------------- QEnforce and QFront Support
  474. Restriction "?"          Moderator: Rob Kitteredge (??:???/???)
  475.  
  476. SUNRISE_DOORS ----------------------------------- Sunrise-80 Software Support
  477. Restriction "?"          Moderator: Al Lawrence (75:7404/2)
  478.  
  479. TDS_ECHO ---------------------------------------------- TDS File Network News
  480. Restriction "?"          Moderator: Adrian Ng (75:500/1)
  481.  
  482. TOPSOFT --------------------------------------------- TopSoft Product Support
  483. Restriction "?"          Moderator: John Richardson (75:7502/2)
  484.  
  485. WWCOMM ----------------------------------------- W & W Communications Support
  486. Restriction "?"          Moderator: Peter Woodmansee (75:7408/2),
  487.                                    Richard Wilkes (75:7408/2)
  488.  
  489.  
  490. *Note: Make sure to see the latest EROSTER.* for an accurate listing
  491.        of available conferences that can be linked.
  492.  
  493. Changes to this Document
  494. ~~~~~~~~~~~~~~~~~~~~~~~~
  495.    "For voting purposes only the REC's of record may vote. An REC of Record
  496. is the individual listed in the weekly nodelist immediately preceding the
  497. vote.  The ZEC only votes in the case of a tie to break the stalemate."
  498.  
  499.    Appeals of ZEC rulings may only be made to the ZC who may rule on the
  500. appeal, dismiss the appeal or refer it to the Executive committee for review.
  501. Whatever the result of this action it is final.  It is normally the policy of
  502. the ZC to uphold decisions of the ZEC.
  503.  
  504. A change to this document may be proposed by any REC.  If a second REC
  505. concurs, the proposed change is voted on by all of the RECs.  Notice
  506. of such a vote is posted both in the D_SYSOP conference and EROSTER.mdd,
  507. at least 30 days prior to the start of the voting period.
  508.  
  509. The RECs are expected to assess the opinions of the members within their
  510. region, and to vote accordingly.  The voting period is 14 days.  More
  511. than 50 percent of those voting must vote for a change for it to be
  512. accepted.  At least 50 percent of the RECs must vote before the amendment
  513. can be ratified into this document.
  514.  
  515.  
  516.  
  517.                                 =end=
  518.  
  519.